In a distributed system of servers and clients, it is often desirable to provide to the clients a Single Sign On (SSO) service. As long as the client uses the same access point, say a workstation, this service avoids the client having to re-authenticate his or her self with any other server that is part of the distributed system. One way to achieve SSO is to use security tokens, where such tokens are assertions described by the Security Assertion Markup Language (SAML), to pass authentication information throughout various domains within the distributed system. However, security tokens may not be sent as-is because the security tokens contain user sensitive information.
To avoid exposing sensitive information, another feature, called an artifact, is used in conjunction with the security token. The artifact is a reference (sometimes referred to as a one-time use opaque handle) to one or more assertions of the security token where the assertion contains key user logon information. The artifact is resolved between the server providing the service to the client and an artifact resolution service available in an identity provider.
FIG. 1 illustrates components of a virtualized desktop infrastructure (VDI) system 100 in which one or more embodiments of the present invention may be implemented. In VDI system 100, VDI client software programs (also referred to as “VDI clients” for short), e.g., VDI client 110, run on operating systems of local computing devices, e.g., client machine 109 on top of an operating system (OS) 111. VDI clients provides an interface for the users to access their desktops, which may be running in one of virtual machines 157 or blade server (not shown) in a data center that is remote from the user locations. The term, “desktop” refers to the instance of an interactive operating environment provided by a computer operating system and software applications, typically in the form of a display and sound output and keyboard and mouse input. With VDI clients, users can access desktops running in a remote data center through network 120, from any location, using a general purpose computer running a commodity operating system and a VDI client software program such as VMware® View™, or a special purpose thin client such as those available from Dell, HP, NEC, Sun Microsystems, Wyse, and others. VDI system 100 also includes an identity provider 104, which includes a network portal 105 and a corresponding client 106 for each VDI client 110. Identity provider 104 connects to user accounts 136 including user log-in information and provide facilities for a single sign on service. The system 100 further includes a gateway/DMZ 108 which may be configured to perform certain client verifications and a connection server 137 that manages connections between VDI clients and desktops running in virtual machines 157 or other platforms. Connection server 137 may run on separate servers or in separate virtual machines running on the same server or different servers. In the embodiments of the present invention illustrated herein, desktops are running in virtual machines 157 and virtual machines 157 are instantiated on a plurality of physical computers 150, 152, 154, each of which includes virtualization software 158 and hardware 159, is controlled by a virtual machine management server 140, and is coupled to a shared persistent storage system 160. All of the components of VDI system 100 communicate via network 120. For simplicity, a single network is shown but it should be recognized that, in actual implementations, the components of VDI system 100 may be connected over the same network or different networks. Furthermore, a particular configuration of the virtualized desktop infrastructure is described above and illustrated in FIG. 1, but it should be recognized that one or more embodiments of the present invention may be practiced with other configurations of the virtualized desktop infrastructure.
FIG. 2 depicts an example flow for an SSO service. In step 202, user 110, a VDI client, launches a request for a resource on a server, which in this case is a connection server 137 such as the Horizon Connection Server®. Next, in step 204, an identity provider 104, such as vIDM, forwards the request to client 106, where the request now contains an SAML artifact. In step 206, client 106, sends an URL with the artifact to gateway 108. In step 208, gateway 108 sends the artifact to connection server 137. In step 210, connection server 137 resolves the artifact with identity provider 104 and in step 212 receives the SAML assertion referenced by the artifact. The resolved assertion contains the user's UPN and AD password, where UPN is the user principal name based on Internet Standard RFC 822 and AD is a Microsoft® Active Directory. From the resolved assertion, connection server 137 permits user 110 to access the requested resource.
However, the example flow depicted in FIG. 2 encounters some difficulties. If an gateway though which the security token passes requires authentication or validation before letting the security token through, then the example flow can fail because the gateway cannot retrieve, view or validate the security token with the artifact. The security token with the artifact can only be resolved by the connection server 137.
FIG. 3 depicts an example flow in which the flow fails to permit a user single sign on because the gateway cannot resolve the artifact. In step 302, user 110 launches a request for a resource controlled by connection server 137. In step 304, identity provider 104 sends to client 106 an URL with a SAML security token which includes an artifact referencing the key user login information. In step 306, client 106 sends the URL with the token containing the artifact to a validating type of gateway 108, such as an F5 Access Policy Manager (APM). Gateway 108 attempts to verify the security token but is unable to do so, because the artifact is issued only for the connection server, which is configured to resolve it using identify provider 104. Thus, gateway 108 blocks the login request from reaching the connection server and the user cannot be granted a single sign on session with the system.
It is desirable to have a way to send a security token to a server with a guarantee that the security token will pass through any and all gateways and allow the security token to accomplish the goal of permitting a Single Sign On (SSO).